🤖 tests: cover sendTreeMessage paths before the split - #7708

…oder#7709)

## Summary

Part 1 of 5: splits the tail of `TaskService.sendTreeMessage` (park,
dispatch and settle) in place into named steps, with no behaviour
change. The method drops from CC 133 to CC 109. On top of the test PR
coder#7708. 460 changed lines.

The parts go from the end of the method to its start, as in the two
earlier stacks (coder#7697 to coder#7699, coder#7702 to coder#7706). The code that stays
inline must be the start of the method, so it can call the extracted
tail with one call.

## Steps in this part

- `dispatchPeerSend` makes the dispatch.
- `refuseStalePeerSendBeforeDispatch` runs the recheck before dispatch.
- `queuePeerSendBehindParked` queues the send behind a parked one.
- `parkPeerSendForDelegatedTurn` is the former `park` closure, and
`waitForDelegatedTurn` waits for the delegated turn.
- `settlePeerSendResult` keeps the refusal order: the delegated-turn
refusal, then the admission refusal, then `send_failed`.
- This part adds the readonly records `PeerSendRequest`, `PeerSendRoute`
and `PeerSendAdmission`, and the mutable `PeerSendAttempt`. In this part
the admission check is still a closure, and `dispatchPeerSend` gets it
as a parameter.

## Rules every part keeps

- The four overloads and the implementation signature of
`sendTreeMessage` do not change. No step calls `this.sendTreeMessage`
again, so the spy in `taskService.delegatedTurnPeerDelivery.test.ts`
still sees every call.
- Every step runs inside `withPeerAdmissionLock(targetId, ...)`, which
is the peer delivery lock plus the target's event lock. No step takes
either lock, and the callback returns the chain, so both locks release
when the chain settles.
- The callbacks that `sendMessage` and the workspace service run later
(`admissionStale`, park, `onCanceled`, `onAccepted`) read and write one
mutable `PeerSendAttempt` record when they run:
`delegatedTurnCorrelation`, `admissionRefusal`,
`refusedAtRegistrationEpoch`, `parkedThisAttempt` and `accepted`.
`admissionStale` stays a plain synchronous function.
- The steps form a chain: each step calls the next one directly after
its own last await, so no collaborator call runs a microtask later. Only
the result of the send settles later, at approximately 2 to 3 microtasks
per chain level. So the two locks also release that much later. A
refusal before the checkout await settles at the same time as before.
- `make crap-check` against the parent commit reports 0 violations, with
and without coverage. Every new function scores CC 8 or less.
- A script compared the old and new code: both have 5 awaits and the
same collaborator calls.

---

_Generated with `xum` • Model: `anthropic:claude-opus-5-5` • Thinking:
`high` • Cost: `$198.09`_

<!-- mux-attribution: model=anthropic:claude-opus-5-5 thinking=high
costs=198.09 -->